As a technique to provide seamless connection of communication network even while moving to users, who want to have access to the communication network such as Internet from a mobile terminal (mobile node) via radio network, a technique is now propagating, which uses mobile IPv6, i.e. the next generation Internet protocol. Now, referring to FIG. 5, description will be given below on a radio communication system using this mobile IPv6. The technique of mobile IPv6 as described here is disclosed, for instance, in the Non-Patent Document 1 as given below.
The radio communication system shown in FIG. 5 comprises an IP network (communication network) 15 such as Internet, a plurality of subnets (also called sub-networks) 20 and 30 connected to the IP network 15, and a mobile terminal (MN: mobile node) 10, which can be connected to one of the plurality of subnets 20 and 30. In FIG. 5, two subnets 20 and 30 are shown as the plurality of subnets 20 and 30.
The subnet 20 comprises an access router (AR) 21 to perform routing to IP packet (packet data) and a plurality of access points (APs) 22 and 23, which constitute specific radio coverage areas (communicatable areas) 28 and 29 respectively. These APs 22 and 23 are connected to AR 21 respectively, and AR 21 is connected to the IP network 15. In FIG. 5, two APs 22 and 23 are shown as the plurality of APs 22 and 23. Also, the subnet 30 comprises AR 31 and a plurality of APs 32 and 33 and has also the same connection aspect as that of the subnet 20.
AR 21 is a component element of the subnet 20 and AR 31 is a component element of the subnet 30, and these can perform communication with each other via the IP network 15. That is, the subnet 20 and the subnet 30 are connected with each other via the IP network 15.
Here, it is supposed that MN 10 initiates radio communication with AP 23 within the radio coverage area 29 in the radio communication system shown in FIG. 5. In this case, if IPv6 address assigned to MN 10 is not suitable to IP address system of the subnet 20, MN 10, which is present in the radio coverage area 29, acquires an IPv6 address suitable for the subnet 20, i.e. care of address (CoA), via radio communication with AP 23.
As the methods, by which MN 10 acquires CoA, there are: a method, according to which CoA is assigned in stateful condition from a DHCP server by the procedure such as DHCPv6 (Dynamic Host Configuration Protocol for IPv6), and a method for automatically generating CoA in stateless condition by acquiring network prefix and prefix length of the subnet 20 from AR 21 and by combining the network prefix and the prefix length acquired from AR 21 with a link layer address of MN 10.
Then, MN 10 can transmit or receive packet data in the subnet 20 by registering the acquired CoA (Binding update (BU)) to a router (home agent) on its own home network or to a specific correspondent node (CN).
As a result, the packet data transmitted from a predetermined correspondent node to MN 10 is transmitted to MN 10 via AR 21 and AP 23, and the packet data transmitted by MN 10 to the correspondent node is delivered to the correspondent node via AP 23 and AR 21. Also, the packet data transmitted to MN 10 via home network is sent to AR 21 of the subnet 20 according to CoA of MN 10 registered at the home agent is delivered to MN 10 via AP 23.
As described above, the radio communication system using mobile IPv6 as shown in FIG. 5 is so arranged that radio communication at MN 10 can be continued by using CoA even when MN 10 performs handover from the subnet where MN 10 is present to another subnet. As a technique to perform this handover processing at high speed, a fast handover technique disclosed in the Non-Patent Document 2 as given below is known, for instance.
In this fast handover technique, MN 10 acquires a new CoA (hereinafter referred as “NCoA”) in advance, which is to be used in the subnet 30 before MN 10 performs L2 handover, and by notifying this NCoA to AR 21, a tunnel can be generated between AR 21 and AR 31. Even during the period for the switchover of the connection from AP 23 to AP 32 in the L2 handover by MN 10 to official registration (BU) of NCoA acquired in advance after moving to the subnet 30, the packet data sent to previous CoA (hereinafter referred as “PCoA”) of MN 10 as used in the subnet 20 can be transferred to MN 10 via the tunnel and via AR 31 and AP 32. Also, the packet data transmitted from MN 10 can reach AR 21 via the tunnel through AP 32 and AR 31 and can be sent from AR 21 to the correspondent node.
On the other hand, in the communication using the network, there are provided services such as QoS (Quality of Service) guarantee (in this specification, these services are referred as “additional services”), and there are various types of communication protocols to realize the additional services. Among these various types of communication protocols, there is RSVP (Resource Reservation Protocol), for instance, as a protocol for providing QoS guarantee (e.g. see the Non-Patent Document 3 as given below). RSVP ensures that the data are transmitted smoothly from a transmission side communication terminal to a receiving side communication terminal by making band reservation on a flow to transmit the data from the transmission side communication terminal to the receiving side communication terminal for receiving data.
On MN 10, which performs handover between the subnets 20 and 30, there are demands that additional services such as QoS guarantee, which has been received before the handover, should be received continuously after the handover. RSVP as described above cannot meet the demands—particularly, in the points as given below, and it cannot cope with the moving of MN 10. FIG. 6 is a schematical drawing to explain that the RSVP based on the prior art cannot cope with the moving of MN.
In RSVP, QoS path is set up on an end-to-end path from a correspondent node (CN) 60 to MN 10, and data transfer is performed by a plurality of relay nodes 61, which connect the points on the end-to-end path based on addresses of MN 10 and CN 60. Therefore, when MN 10 performs handover between the subnets 20 and 30 and CoA of MN 10 has been changed, a processing relating to address change must be carried out in addition to the change of flow on QoS path. RSVP cannot cope with such change, and the QoS guarantee cannot be fulfilled as a result (a first problem: difficulty to change QoS path). Further, even when QoS path is set up newly, if overlapping occurs on QoS path before and after the handover, double reservation may be made on the overlapping portion (a second problem: double resource reservation).
To solve the problem as described above, discussions are currently going on to standardize a new protocol called NSIS (Next Step in Signaling) in IETF (Internet Engineering Task Force). Much expectation is put on NSIS as it is particularly effective for various types of additional services such as QoS guarantee, and there are documents where the requirements to realize QoS guarantee or mobility support in NSIS or the methods to attain the purpose are described (e.g. Non-Patent Documents 4-8 as given below). Description will be given now on general features of NSIS, which is currently a draft specification by NSIS working group of IETF, and on the method to establish QoS path (see Non-Patent Document 5 and Non-Patent Document 8).
FIG. 7 shows protocol stack of NSIS and its lower layer to explain the protocol arrangement of NSIS in the prior art. NSIS protocol layer is positioned immediately above IP and lower layer. Further, the NSIS protocol layer consists of two layers: NSLP (NSIS Signaling Layer Protocol), which is a protocol for generation and processing of signaling message to provide additional services, and NTLP (NSIS Transport Layer Protocol) to perform routing of signaling message of NSLP. There are various types of NSLPs: NSLP for QoS (QoS NSLP), and NSLP for other additional services (service A and service B) (NSLP for service A, NSLP for service B), etc.
FIG. 8 is a schematical drawing to explain the concept that NE and QNE, i.e. nodes of NSIS in the prior art, are “adjacent to each other”. As shown in FIG. 8, at least NTLP is packaged in all nodes with NSIS functions (NE: NSIS Entity). Above this NTLP, NSLP may not be necessarily provided, or one or more NSLPs may be present. Here, NE having NSLP for QoS is referred as QNE (QoS NSIS Entity). A node (terminal) or a router is entitled to become NE. Also, among NEs adjacent to each other, there may be a plurality of routers, which are not NE. Further, among QNEs adjacent to each other, a plurality of routers, which are not NE or a plurality of NEs without QoS NSLP may be present.
Next, description will be given on an example of a conventional method to establish QoS path by referring to FIG. 9. It is supposed here that MN 10 connected to AR 21 in the subnet 20 is scheduled to receive the data from CN 60 or is receiving (currently receiving) the data for a certain purpose (session). When establishing the QoS path, MN 10 transmits a RESERVE message to establish QoS path to CN 60. This RESERVE message contains a QoS information (Qspec) as desired for the receiving of the data from CN 60. The transmitted RESERVE message passes through AR 21 and QNE 62 and other routers without NSIS functions (not shown) and reaches QNE 63. NSLP of QNE 63 reserves QoS resource described in Qspec included in the RESERVE message for this session. After passing through QNE 63, the RESERVE message reaches QNE 65 via NE 64 and other routers without NSIS functions (not shown). At QNE 65, also, the same processing as in QNE 63 is performed, and QoS resource reservation is made. This procedure is repeated. Finally, when the RESERVE message reaches CN 60, QoS path is established between MN 10 and CN 60.
To identify the resource reservation, a flow identifier and a session identifier are used. The flow identifier depends on CoA of MN 10 or IP address of CN 60. Each of QNE 63 and QNE 65 can know whether resource reservation for the data packet is present or not by confirming IP addresses of transmission source and transmission destination of each data packet. In case MN 10 moves to the other subnet and CoA is changed, the flow identifier is also changed to cope with the change of CoA of MN 10. On the other hand, the session identifier is to identify a series of data transmission for the session, and, unlike the case of the flow identifier, it is not changed in association with the moving terminal.
There is a method called as QUERY as a method to check the availability of QoS resource to an arbitrary path. This is a method to check in advance whether a desired Qspec can be reserved by each QNE when QoS path is established from MN 10 to CN 60, for instance. A QUERY message to check whether the desired Qspec can be reserved or not by QNE is transmitted, and the result can be received by a RESPONSE message, which is a response to the QUERY message. Current resource reservation condition does not change due to the QUERY message and the RESPONSE message. In order that a QNE gives some notification to other QUE, a NOTIFY message can be used. This NOTIFY message is used for the purpose such as notification of error. RESERVE message, QUERY message, RESPONSE message and NOTIFY message are the messages of NSLP for QoS guarantee, and these are described in the Non-Patent Document 5.
Also, QUERY is used not only to check the availability of QoS resource but also to check the path for resource reservation in advance. That is, by sending a QUERY message from data transmission side to the data receiving side, it is possible to specify the path where the data may pass. The resource reservation is performed to QNE on the path specified by this QUERY.
However, in actual network, it is possible that the data path is deviated from the path where resource reservation has been made. No discussion has been made almost at all on how to avoid this, while, in the Non-Patent Document 8 as given below, a method such as route pinning to fix the path where the data passes is given as one of the measures to solve the problem.
Next, referring to FIG. 10, description will be given on a method to avoid double resource reservation when MN 10 has moved from the subnet 20 to the subnet 30 in the prior art. When MN 10 is receiving data from CN 60 and when QoS path (path 124) is established, QoS resources as desired by MN 10 are reserved at QNE 63, QNE 65 and QNE 66. It is assumed here that the flow identifier and the session identifier in this case are X and Y respectively. Actually, current IP address of MN 10 and IP address of CN 60 are contained in the flow identifier X. Also, an arbitrary numerical value high enough is set in the session identifier Y. Under this condition, after MN 10 has moved to the subnet 30, a RESERVE message is sent to CN 60 to establish a new QoS path. The previous path (path 124) is not immediately released after the moving of MN 10.
As already described, the flow identifier is changed in association with the moving of MN 10. Thus, the flow identifier X in the path 124 and the flow identifier in the path 134 (the flow identifier in the path 134 is referred as Z) are different from each other. Because there is no resource reservation to the session identifier Y in any of the interfaces, QNE 67 judges that a new path has been established, and resource reservation is made to the flow identifier Z and the session identifier Y. On the other hand, resource reservation to the session identifier Y is present at QNE 65 and QNE 66. QNE 65 and QNE 66 compare the flow identifier X with the flow identifier Z. If it is confirmed that the flow identifier has changed from X to Z, it is judged that a new path has been established due to the moving of MN 10. To avoid double reservation, means are taken to update the previous reservation by making new resource reservation. A QNE, where a previous path and a new path begin to cross over, is called a crossover node (CRN). CRN may indicate a router where the paths actually cross over (NE 64 in FIG. 10). When discussion is made on QoS path, it relates to a QNE (QNE 65 in FIG. 10) where one of adjacent QNEs (QNE 66 in FIG. 10) is the same but another of the adjacent QNEs (QNE 63 and QNE 67 in FIG. 10) is different in the previous path (path 124) and the new path (path 134).
According to the Non-Patent Document 5 or the Non-Patent Document 8, in the RESERVE message, in the QUERY message and in the NOTIFY message, not only the terminals at the end (MN 10 and CN 60), which are transmission destination or transmission source of the data packet, but also an arbitrary QUE may also become the transmission source.
NSIS covers various types of functions not only in mobile environment, but also in normal static network. In the present specification, special notice is given on the functions to actualize the establishment of additional services supported by mobility support, which is one of the functions of NSIS, and it is assumed that the additional services under mobility support can be achieved by the packaging of NSIS.    [Non-Patent Document 1] D. Johnson, C. Perkins and J. Arkko, “Mobility Support in IPv6”, draft-ietf-mobileip-ipv6-24, June 2003    [Non-Patent Document 2] Rajeev Koodli “Fast Handovers for Mobile IPv6”, draft-ietf-mobileip-fast-mipv6-08, October 2003    [Non-Patent Document 3] R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, “Resource ReSerVation Protocol—Version 1 Functional Specification”, RFC 2205, September 1997.    [Non-Patent Document 4] H. Chaskar, Ed, “Requirements of a Quality of Service (QoS) Solution for Mobile IP”, RFC3583, September 2003    [Non-Patent Document 5] Sven Van den Bosch, Georgios Karagiannis and Andrew McDonald “NSLP for Quality-of-Service signalling”, draft-ietf-nsis-qos-nslp-01.txt, October 2003    [Non-Patent Document 6] X. Fu, H. Schulzrinne, H. Tschofenig, “Mobility issues in Next Step signaling”, draft-fu-nsis-mobility-01.txt, October 2003    [Non-Patent Document 7] Roland Bless, et. Al., “Mobility and Internet Signaling Protocol”, draft-manyfolks-signaling-protocol-mobility-00.txt, January 2004    [Non-Patent Document 8] R. Hancock (editor), “Next Steps in Signaling: Framework”, draft-ietf-nsis-fw-05.txt, October 2003    [Non-Patent Document 9] Takako SANDA et al.; “A Proposal for Seamless QoS Support in Mobile Networks”; The Institute of Electronics, Information and Communication Engineers, Technical Report of IEICE, Mobile Multi-Media Communication (MoMuC); May 2004.
In FIG. 10, let us imagine a case where MN 10 with QoS guarantee in the subnet 20 before handover performs handover to the subnet 30 and continuously receive after the handover the QoS guarantee which has been received before the handover in the subnet 30, to which it was connected.
In this case, MN 10 cannot receive QoS guarantee during the period from the hand-off from the subnet 20, to which MN 10 has been connected before the handover, up to the time when it is turned to the condition to receive additional services (QoS guarantee in this case) in the subnet 30 where it is connected after the handover. MN 10 cannot receive QoS guarantee at all, or default QoS transfer processing is carried out. This means the breakdown of QoS.
As described above, therefore, QoS guarantee must be quickly provided to MN 10 after the handover. To solve this problem, in the current discussion on NSIS in IETF (e.g. the Non-Patent Document 6), it is proposed that some preparation to establish a new QoS path before MN 10 performs the handover or before the handover is completed, or that a new QoS path must be established in advance. Regarding this point, in the Non-Patent Document 9, for instance, it is suggested to use a method to make preparation for establishing QoS path in advance as a proxy within or near the subnet of the destination transmits and receives a signaling message to and from CN 60. However, when MN 10 is currently in communication with CN 60, which is located at a separated position, the round trip of the signaling message may impede smooth operation of handover.